A monotonic counter may be implemented to produce increasing values or decreasing values. For the increasing values implementation, once the count value changes to a higher number, it should not thereafter exhibit any value less than the higher number. For the decreasing values implementation, once the count value changes to a lower number, it should not thereafter exhibit any value greater than the lower number. For either implementation, the monotonic nature of the count value should be maintained throughout the life of the device in which the monotonic counter operates, including across any number of power-on and power-off cycles.
Secure computing devices perform operations and/or are otherwise configured to ensure the legitimacy, integrity, privacy, and/or authenticity of at least some of the data they process. Such devices may use a secure microprocessor or the like, which includes physical and logical features to provide a secure execution environment (SEE). The SEE, also called a trusted platform, security zone, and the like, may include software and/or hardware features which promote a high level of trust in the data security operations the device may undertake, making the security features of the device nearly immune to malicious software that the device may accidentally or intentionally execute from time to time. Desirably, a monotonic counter is implemented as part of the SEE so that its monotonic operation is nearly immune to malicious software and so that its monotonic count value may be trusted to a high degree of confidence throughout the normal life of the device.
As an example, secure computing devices may rely upon monotonic counters to implement offline, decentralized applications, and other applications that might otherwise be prone to replay attacks. Replay attacks represent a type of malicious activity where data, including encrypted data, which were perfectly legitimate at an earlier time, are replayed at a later time, after the data has become illegitimate. Without some feature, such as a monotonic counter, the now illegitimate data may decrypt successfully, leading to an illegitimate use of the data.
An off-line payment system represents an exemplary application that may use a monotonic counter to prevent replay attacks. In this exemplary application, a credit issuer stores credit balances on users' secure computing devices. When a user makes a purchase, a merchant may verify the credit balance and reduce this balance using data stored on the user's device, all without communicating with the credit issuer. The balance verification and reduction may be accomplished using a secure cryptographic encryption scheme known only to the credit issuer and the merchant. The encryption scheme allows the credit issuer and merchant to be confident that the user has not altered data previously written on the user's device. But the merchant and credit issuer also want to be confident that the user's device is not merely replaying a previously legitimate higher credit balance in an attempt to double-spend the user's credit. Thus, when a transaction takes place with a merchant, the merchant may increase a monotonic counter in the user's device, and then write a data object to the user's device that stores an encrypted version of the new count value, a new credit balance, and a digital signature. Later, when the same or a different merchant investigates the user's credit balance, the merchant may verify that the recorded count value encrypted in the data object matches the actual monotonic counter's then-current output and be confident that no replay attack is being attempted. If a replay attack were being attempted, the actual monotonic counter output would be higher than the recorded count value encrypted in the data object. If the monotonic counter is not securely monotonic, the device which relies upon the monotonic counter will be susceptible to a replay attack. Many other applications may also benefit from the use of a monotonic counter, including virtual trusted storage, e-wallet, and digital rights management.
Conventional secure computing devices with monotonic counters include a variety of hardware and software techniques to determine whether a security breach has occurred. These techniques are used in accordance with a design philosophy that believes users should use their secure computing devices in a manner that does not lead to a breach in security. Consequently, certain possible events which are deemed to be security breaches lead to the conclusion that the secure computing device has been compromised and should not thereafter be reused.
This conventional scheme for declaring secure computing devices with monotonic counters to be unusable after a security breach is too harsh. Secure computing devices with monotonic counters may be expensive devices, and they may be the property of their users, who will be unhappy to have their expensive devices being declared unusable.
Moreover, security may be deemed to be breached for a variety of reasons, some of which do not truly suggest a security problem. In order to have a low probability of false negative errors in declaring security breaches, the designs of some secure computing devices may accept a larger probability of false positive errors than is desirable. In other words, in order to catch virtually all legitimate security breaches, a secure computing device may declare some events as security breaches which should not be so declared. For example, the removal or failure of a battery that energizes certain security features in the SEE may be viewed as a security breach in some devices. And, normal human accidents which lead to dropping a secure computing device, immersing it in water, overheating it, and the like, may be viewed as security breaches even though the affected devices may otherwise be functional or easily be made functional after the accidents.